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Foreword 

This Technical Speciftcation has been produced by Ericsson, Siemens. Motorola and Nokia. 

introduction 

This technical specification describes an architecture that iiiinis the user requirements described in reference [I]. 

The basic architecture is described in clause 4. 

The functional entities of the architecture are described in clause 5. 

The interfaces of the architecture are descrit>ed in clause 6. 

General system concepts, that have architectural implications, are described in clause 7. 

An overview of the high level procedures, for informational puiposes, is described in clause 8. 
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1 Scope 

This document describes the functional entities, interfaces, system concepts and high-level procedures of the Push-to- 
Talk over Cellular (PoC) service. 

The PoC seivice is characterized by a half duplex form of communication whereby one user will communicate with 
lier uS« S pr^^n^ b"«^^ (or P-for^-B -'•"-alent action) on an PoC enabled User Equ.pmcnt (UE). 

This specification is part of PoC release 1.0. 

References 

The following documents contain provisions, which through reference in this text constitute provisions of the 
present document. 

. References are either specific (identified by date of publication, edition number, version number, etc.) or 
non-specific. 

• For a specific reference, subsequent revisions do not apply. 

. For a non-specific reference, the latest version applies. In the case of a referettce to a P<»C document, a 
non-s^ific^^ference implicitly refers to the latest version of that document m the same Release as .he 
present document 

J Push-to-Talk over Cellular User Requirements; PoC Release 1 .0 

[2] PoC Signaling Flows; PoC Release 1 .0 

f3j PoC User Plane; Transport Protocols; PoC Release 1 .0 

[4j PoC User Plane; (E)GPRS Specification; PoC Release 1 .0 

j^5j PoC List Management and Do-Not-Dismrb; PoC Release 1 .0 

ffl 3GPP TS 23.228 "Technical Specification Group Services and System Aspects; TP Multimedia 

Subsystem (IMS); Stage 2 (Release 6)" 

30PP TS 24.008 "Mobile radio interface Layer 3 specification; Core network protocols; Stage 3" 
3GPP TS 24.229: "IP Multimedia Call Control Protocol based on SIP and SDP; Stage 3 (Release 

5r 

IETF RFC 1332 "The PPP Internet Protocol Control Protocol (IPCP)" 

IETF RFC 1877 "PPP Internet Protocol Control Protocol Extensions for Name Server Addresses" 

[11] IETF RFC 1 889 "RTP: A Transport Protocol for Real-Time Applications" 

[12] IETF RFC 2616: "Hypertext Transfer Protocol HTTP/M" 

J J 3 J i£TF RFC 326 1 : "SIP: Session Initiation Protocol" 

[14] IETF RFC 3263: "Session Initiation Protocol (SIP): Locating SIP Swvers" 

IETF RFC 3320: "Signaling Compression (SigComp)" 

[16] IETF RFC 3321 : "Signaling Compression (SigComp) - Extended Operations" 

[17] IETF RFC 3485: "The Session Initiation Protocol (SIP) and Session Description Protocol (SDP) 

Static Dictionary for Signaling Compression (SigComp)" 

IETF RFC 3486: "Compressing the Session Initiation Protocol (SIP)" 



m 

[SI 

PI 
[10] 
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[19] IETF < draft-ietf-sip-callerprefs-09.txt> (expire December 29, 2003): "Caller Preferences for the 

Session Initiation Protocol (SIP)** 

.f20] IETF <draft-ietf-simpIe-presence-lO,txl> (expires July 2003): "A Presence Event Package for the 

Session Initiation Protocol (SIP)" 

[21] ITU-T Recommendation £.164: "The international public telecommunication numbering plan" 

[22] IETF RFC 2486: "The Network Access identifier^. 

[23] IETF RFC 2806 "URLs for Telephone Calls" 

3 Definitions and abbreviations 
3,1 Definitions 

For the purposes of the PoC specifications, the following terms and definitions apply. 

Access control: Each PoC user can define rules that describe who is allowed to contact him/her using the PoC service. 
The PoC Server implements the access control policy according to these defined rules. 

Access list: Each PoC user has two access lists: a user accept list and user reject list. Access lists are used for 
controlling whether the PoC server is allowed or not to send talk session requests to the user when i^equested by other 

user. 

Ad-hoc instant group talk: A feature providing a user to ad-hoc establishes a PoC session with other PoC users. 

Chat group: A persistent group created for chat group talk. Each group member joins the talk session individually. 

Chat group talk: A feature providing users with the capability to join a pre-defined chat group. The chat group may be 
open or restricted. ^ r ^ 

Chat talk session: A talk session established by a chat group talk. 

Contact list: A list available to the end user containing the addresses of other users or groups. 

Contact: A contact is an identity of a user, or a group. A contact includes the SIP URI or a TEL URI of the entity, type 
of the entity (user or group) and optionally the display name. 

Floor control: A control mechanism that arbitrates requests. fix>m the UEs, for the right to speak. 
Group Talk: An instant group talk, ad-hoc instant group talk or chat group talk. 

Group: Group is predefined set of users together with its attributes. The group is used for easy session establishment 
and/or for defining session access policy. Each group is identified by its SIP URI. 

Instant group: A persistent group created for instant group talk. The users PoC server invites all the other croup 
members to a talk session. 

Instant group talk: A feature providing a user to establish a PoC session with other members in a predefined instant 
group. The instant group is always a restricted group. 

Instant personal Alert: A feature providing a user with the capability to send a callback request to another user. 
Instant personal talk: A feature to establish a PoC session with another user. 

Instant talk session: A talk session established by instant personal talk, ad-hoc group talk or instant group talk. 

Invited user: This is the PoC user who has been invited to a talk session. 

Inviting user: This is the PoC user inviting other PoC user(s) to the to a talk session. 
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„ed.. capabilities list: In this list, .he PoC Server shall store the downlink media capabilities of all UEs that are actwe 
in sessions served by the PoC Server. 

agreed upon etc). 

. ..TU. Par Server uses the media capabilities list to determine the settings the user equipments 
media parameters: The PoC Server uses inc . ^ . in ortier to alter the settmgs 

rr^Nri?:hfd=.s::^sr^^^^ 

Open group: A group that can be joined by any user. 

Participant: A PoC user in talk session. 

r ^ , OTP narWrt the UE needs to be able to receive the media stream on its downlink. Ptime « 
«:SS:e^nS^^^^ 

Restricted group: A group that can be joined only by predefined user^s). 

Session ; A session is considered as an exchange of data between associations of participants. 

Talk session: TOs is an esublished connection between PoC users where the users can communicate one at a time m a 
half duplex manner. 

talk spurt: A pan of the speech signal that starts with a speech onset and ends when the speech coder goes down in 
DTX-mode, Hence a talk burst can consists of several talk spurts. 

Talk-burst: The media recording, transport and playback that occur from when the user has the floor. 

User: A human using the described feamres through a terminal device. 

User accept list; User accept list is a list of items each identified by its SIP URl. 

User equipment: User equipment is a hardwai. device (e.g. phone) with Push-to-Talk software used by users. 
User reject list: User reject list is a list of items each identified by its SIP URI. 



3.2 Abbreviations 

For the purposes of the PoC specifications, the following abbreviations apply: 

AMR Adaptive Multi Rate 

DNS Domain Name System 

DTD Document Type Definition 

FQDN Fully Qualified Domain Name 

FPS For Further Study 

GERAN GSM/EDGE Radio Access Network 

GGSN Gateway GPRS Support Node 

GLMS Group and List Management Server 

HTTP Hypertext Transfer Protocol 

IMS IP multimedia subsystem 

IPCP Internet Protocol Control Protocol 

ISC IMS service control interface 

MD5 Message Digest no. 5 

N/A Not Applicable 
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NAI Network Access IdeniiTicr 

NAPTR Naming Authority Pointer 

P-CSCF Proxy-CSCF 

PCO Protocol Configuration Options 

PDP Packet Data Protocol 

PoC PTT over Cellular 

PIT Push to Talk 

RTCP RTP Control Protocol 

RTP Real-time Transport Protocol 

SIP Session Initiation Protocol 

SRV DNS resource record for the location of services 

UCS Universal Character Set 

U£ . User Equipment 

URI Uniform Resource Identifier 

URL Uniform Resource Locator 

UTF-8 UCS Transforation Format 8 

UTRAN Universal Terrestrial Radio Access Network. 

XML Extensible Mark-up Language 

3.3 Requirement vocabulary 

Shall Indicates a mandatory requirement. 

Should Indicates a recommendation. 

May Indicates an optional requirement. 
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4 Architecture 

The PoC fiinctk>nal architecture is outlined in Figure 1 . 
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Figure 1 : PoC architecture 
NOTC: TTie access in the PoC architecture includes both the mdio access as well as the other nodes required to 
gain IP connectivity (c.g. GSNs). 
PoC shall be based on IMS as specified in 3GPP TS 23.228 (6] and TS 24.229 [71. with exceptions regarding to: 

IPv4 only is supported. 

- The IMS-enabled PoC service may be offered through mobile networks different from that specified in 3GPP 
S«se 5. -n^is implies modified interfaces to the networic envitonment for rn^e areas of chargmg and QoS 
support, and a modified authentication mechanism and modifications m the SIP signaling. 

specifications. 

NOTE- When PoC service is offered through a mobile network according to 3GPP release 5, and subsequent IMS 
releases. IMS signaling as defined by 3GPP shall be complied to. 
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5 



Description of functional entities 



5. 1 User Equipment (UE) 



The UE is the terminal equipment containing the PoC application client software. 



5.2 



IMS Core 



The IMS core includes a number of SIP proxies and SIP registrars according to [6] and [13]. The first point of contact 
for UE is one of the proxies in the IMS core that is configured on the UE as the outbound proxy. In the IMS 
architecture, the outbound proxy is known as the P-CSCF. The IMS Core performs the following amctions: 

Routes the SIP signaling between the UE and the PoC Server, 

Terminates the SIP compression from the terminal; 

Authentication and authorization; 

Maintains the registration state and the SIP session state; 

Reporting to the charging system. 

The UE shall send all its SIP messages to the IP address of the outbound proxy after resolving the SIP URI of the 
outbound proxy to an IP address. 



PoC users use the GLMS to manage groups, contact lists and access lists. 

"A contact list is a kind of address book that may be used by PoC users to establish an instant talk session with other PoC 
users or PoC Groups. A user may have one or several contact lists including identities of other PoC users or PoC 
Gn>ups. Contact list management includes operations to allow the UE to store and retrieve the contact lists located in 
the GLMS. 

The end users can define PoC groups. The end user may select one group from the list to initiate an instant group talk 
session or a chat group talk session depending on the type of the group. 

An access list is used by the end user as a means of controlling who is allowed to initiate instant talk sessions to the end 
user. An access list contains end user defined identities of other PoC end users or groups. The end user may have one 
blocked identities list and one granted identities list. 



The PoC Server contains the PoC service. The PoC Server performs the following functions: 
End-point for SIP signaling; 
End-point for RTP and RTCP signaling 
Provides SIP session handling 
Provides policy control for access to groups 
Provides group session handling. 
Provides access control 
Provides do not disturb functionality. 
Provides the floor control functionality; 



5.3 



Group and List Management Server (GLMS) 



5.4 



PoC Server 
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Provides the Talker identification 
Provides the Participants information 
Provides the Quality feedback 
Provides the Charging reports 
Provides the Media distribution. 

5.5 Presence Server 

The presence server is not standardized in PoC release l.O. 
receives from multiple sources into a single presence document 



Description of the interfaces 
6 1 Interface Is: UE - IMS Core 

Tl^e Is interface supports .he communication between the UE and the IMS Core.. This communication includes the SIP 
procedures defmed in [2] to support the PoC features defined.m [\]. 

, • ^ ■ ciDf<^ A^med bv 1131 Other relevant IETF RFCs and necessary additions from [8]). 

transported on UDP. 

NOTEl • TCP transport for the Is Interfaces is not supported in PoC release 1.0. 

NOTE2: Presence service inten.ctions between the UE and the IMS co« will be specified in a future PoC release. 

6 2 Interface If: IMS Core -PoC Server 

■n.'e protocols over If interfece support the communication between the IMS core and the PoC Server for session 
control. 

NOTE: The If interface is not specified in the PoC release 1.0. 

6.3 Interface It: UE - PoC Server 

■n,e p«>toco.s over It interface support the transport of talk bursts, floor contn,! and link quaUty messages between the 
UE and the PoC Server. 

•me protocols for the It interface are RTP and RTCP [1 1] with details described in [3]. 

6 4 Interface Im: UE - GLMS 

The HTTP/XML protocols shall be used as defmed m [5]. 
The group and list management operations are detailed in [51. 
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6.5 Interface Ik: PoC Server - GLMS 

The protocols over Ik interface support the communication between the PoC Server and the GLMS; enabling the PoC 
Server to retrieve the groups and access lists from the GLMS. 

NOTE: The Ik interface is not specified in the PoC release 1 .0. 

6.6 Interface Ips: IMS core - Presence Server 

The protocols over Ips interface enable the uploading of the registration status from the IMS core to the Presence Server 
and the dissemination of the presence information between the presence server and the UE. 

NOTE: The Ips interface is not specified in the PoC release 1.0. 

6.7 Interface Ipl: Presence Server - GLMS 

The protocol over Ipl interface enables the uploading of the Do-not-Distuib status and the granted/blocked access lists 
from the GLMS to the Presence Server. 

NOTE: The Ipl interfoce is not specified in the PoC release 1 .0. 

7 System concepts 
7.1 Identification 

7.1 .1 Address of record (a.k.a. public user identity) 

The PoC operator shall assign, to each user, an address-of-record (also known as public user identity) in the form of a 
SIP URI where the user, part of the URI uniquely tdentilies the user, and this could be an alphanumeric string. The host 
part of the URI uniquely identifies a domain owned by the operator. The address-of-record shall comply with the 
specification of a SIP URI in [13]. 

The address-of-record is used for PoC only or for PoC and other SIP based services. 
Examples of addres&K>f-records are: 

sip:joe.doe@operator.net; 

sip:buss2.clty@operator.net; 

sip:buss2.city@poc.operator.net. 

7.1.2 Private user identity 

The network operator shall assign to the user a private user identity for authentication purposes. The private user 
identity shall be hidden from the other users and cannot be used for addressing. 

The private user identity shall take the form of an NAI, and shall have the form usemame@realm as specified in section 
3 of RFC 24$6 [22]. It is configured in the UE. 

7.1 .3 Group identities 

The group identity used on the Is interface (between the UE and IMS core) for group talk, shall be generated by the 
GLMS and shall comply with the specification of a SIP URI in [13]. The GLMS shall generate the group identity 
according to reference [5]. 
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7 1 .4 Contact list identities 

.A^,^^ it^x\x\ and shall be uscd to addfcss the contact lists in the 



GLMS. The GLMS shall generate a 

7.2 Addressing 
7.2.1 IP addresses 

Each entity in the PoC system shall be assigned one or 
IPv4 is mandatory. 



more IP addresses belonging to public or private IP realms. 



7 2 2 Phone numbers 

A POC user may address another user by aphone number. TheUE shall send the phone number tothe IMS cor. In a 
TEL URL [23] 

E.164 format before DNS/ENUM is used. 

7.2.3 SIP URI 

A PoC user may address another user by a SIP URI. 

7.3 Routing principles 
7.3.1 Registration 

ThePoCusershallregisterltselfv.5ththeIMScorebeforeusingthePoCservice. 
URI in the Contact header. 

..eUEshal. indudethemediafeatureu^[191indicatingthe POC service in thcConta^ 
use Ais information forroutmg. 

7 3 2 Session establishment 

Contact header. , ♦ lu ri 

is assigned according to reference [21 

INVITES. 

The transientgroup identity is generated by the POC server and distributed totheUE in the contact header. 
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From che initiating UE, the public user identity or the inviting user shall be included in the From header. On the 
signaling towards the invited user, the From header includes either the public user identity (instant personal talk, ad-hoc 
instant group) or the group identity (instant group talk or being added to a chat group). 

7.3.3 User location 

Users shall use the Address of record or phone number (as described in 7.2.2 and 7.2.3) of other users to address them. 
The IMS core is responsible for routing the requests to the users according to the bindings established through 
registrations. 

7.4 Security 

7.4.1 Threats 

There are a number of SIP threats identified in [13]. The main problem is that it is simple to steal and use another 
user*s identity unless the identity is properly authenticated. The main threats by unauthorized use of an identity are 
according to [13]: 

R^istration Hijacking; 

- . Impersonating a Sender; 

Tearing Down Sessions. 

Another threat is fraud where a malicious user steals another user*s identity to talk and let the other user pay for that. 

7.4.2 Countermeasures 

The best and simplest countermeasure to the threats above is to properly authenticate the SEP requests fix>m a user. The 
Digest procedure defined in [13] shall be supported between the UE and IMS core for authenticating the user. The UE 
shall include any stored credentials in all relevant SIP requests to avoid unnecessaiy signaling. With the digest 
procedure, the IMS core should challenge the user if a relevant SIP request lacks credentials or the credentials are 
invalid. The details for the authentication procedure are defined in [2]. 

A user shall be authenticated with the GLMS by using the procedures defined in [5]. 

In the case of HTTP digest, then the same digest password should be used by the UE when communicating with GLMS 
or IMS core. The UE should not prompt the user for a digest password if the password is configured in the UE. Any 
configured password should be protected, for example, by encryption. 
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7.5 Floor control 

Floor control includes the following actions: 

The acd^^^^ the capability for a participant in a talk session to ask for permission to talk. 

- floor release; 

The action taken be a granted user to release their permission to talk. 

An°a Jion from the network to inform requesting participant that the floor has been granted. 

- floor idle indication; _ 
An action from the network to inform participants that the floor is idle. 

A^actfon from the network to infoim the requesting participant that the floor request is denied. 

A^LSn "Lm the networic to inform all participants that the floor has been granted to the Indicated user. 

^aSfrom the network to remove the permission to talk from a user who has previously been granted 
the floor 

- talk burst quality feedback. i. .t,^ 
reports the amount of media received by the PoC server or by the UE. 

RTCP BYE* 

indicates that tfie sending par^ wants to terminate the ongoing media session In current communication 
context, without changing the SIP-session state 

The talker arbitration performed through the use of RTCP. 

The talker identification distributed through the use of RTCP 

The talk burst quality feedback is distributed through the use of RTCP RR and SR 

Floor control is described in detail in (3]. 

7.6 Codecs 

PoC has the AMR speech codec as the mandatory speech codec for the GSM, GERAN ^^d^TRAN rzdio access 
net^i^orks. The details describing how AMR is used in PoC is found in [3]. The codec rate depends heavily on the radio 
cell configurution and the latency for GSM/GERAN/UTRAN. 

7.7 Signaling compression 

The UE and the IMS core shall compress the SIP signaling according to [15], [16], [17] and [18] to reduce the 
transmission delays. Details how this is done are described in [2]. 

The grouping of messages (compartments) starts at registration and ends at de-registration. 

A static SIP dictionary [17] shall be stored locally in the UE and the IMS core. A user specific dictionary [16] may be 
uploaded by the UE to the IMS core and stored there as part of the registration procedure. The user specific dictionary is 
used to increase the compression rate in particular for the initial SIP messages. The SIP URl shall include the signalmg 
compression Indication as described in [18]. 
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7.8 User plane adaptation 

The media throughput is affected by the conditions on the radio access link. The talk burst (user plane) bit rate shall be 
reduced in case the talk burst bit rate is higher than the available end-to-end bit rate. The available bit rate is indicated 
with RTCP. The talk bursts bit rate can be reduced if necessary by re-negotiation with SIP. 

7.9 Charging 

The charging models that should be supported are described in [1]. The PoC architecture shall be able to support the 
following online charging mechanisms to support these charging nK)dels: 

The IMS core network nodes and the PoC Server shall be able to report to the charging system upon reception 
of various SIP methods since charging relevant information is contained in these messages; 

The PoC Server shall be able to report a talk burst end event to the charging system. The message sent to the 
charging system for the talk burst should include any relevant SCP and SDP parameters for the ongoing session, 
the numbers of bytes sent, the number of packets sent and the duration of the talk burst. 

The PoC Server shall be able to report to the charging system the number of packets and bytes a U£ has 
received in a talk burst The UE reports these parameters in a receiver repon message; 

The delivery of the receiver reports and the talk burst end are not reliable. The PoC Server shall be able to 
report to the charging system after a timer expiry in case both of these messages are lost. v 

The receiver report cannot be trusted. In case there is a long-term difference between the number of bytes sent from 
PoC server and the information received in the receiver report, this is an indication of fraud. 

The bearer charging is also used in parallel. The correlation between the bearer charging and service chaiging shall be 
done in the charging system. 

A deployed network may implement all, some or none of the charging models described in this sub-clause. 

7.10 Roaming 

The PoC user may roam in a visited network. GPRS roaming can then be used which means that a home GGSN and the 
home IMS core are always used. 

7.11 Presence 

For further study 

7.12 Do-not-Disturb 

The user can enable the Do-not-Disturb (DnD) feature in the U£. The network or the UE with die enabled DnD will 
then reject all incoming sessions. The inviting user does then recognize the response as a busy indication. 

The user updates the DnD setting in GLMS. This is described in detail in [5]. 



8 High level procedures 

The clause gives examples on PoC signaling procedures. Details are described in the Signaling flows [2] 
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8.1 PDP Contexts 

A PDP Context with the interactive traffic class with the highest priority should be used for the SIP, DNS and 
HTTP/XML signaling. The signaling PDP Context is a Primaiy PDP Context that shall be activated before the SrP 
registration. This PDP Context should be activated at least as long as the SIP registration lasts. 

In case the radio access network does not support the streaming class or the streaming class usage is subject to local 
policy, a PDP Context with the interactive traffic class with the highest priority should be used for media. The Primary 
PDP Cbntext may be used for the media. As an alternative a Secondary PDP Context with the interactive traffic class 
may be used for the media instead of the Primary PDP Context. 

In case the radio access network supports the streaming trafHc class and the local policy allows its usage PDP Context 
with the streaming traffic class should be used for the media to provide high quality voice. The PDP Context for the 
streaming traffic class is a Secondary PDP Context that is activated in parallel with the establishment of Instant 
Personal Talk or Croup Talk* 

8.2 DNS name server discovery 

The UE obtains IP addresses of the DNS name servers as part of the PDP context activation. 

The IPv4 addresses for the DNS name servers (primary and secondary) are included in the Protocol Configuration 
Options (PCO) [7]. The PCO format uses the IPCP [9] field that is defined in [10]. 

8.3 DNS procedures 

8.3.1 SIP URI resolution 

The address of the outbound proxy in the IMS core is configured into the UE in the form of a SIP URI. The URI should 
include the transport protocol (UDP) and the port number the proxy is listening to and an indication that compression 
should be used (comp=sigcomp). 

In order to contact the outbound proxy, the UE performs a DNS query on the host part of the SIP URI of the proxy 
following the rules described in [14]. Note, however, that if the host part is an IP address rather than an FQDN the UE 
does not need to consult the DNS. 

Note that if the SIP URI of the outbound proxy that is configured in the UE follows the format recommended above 
(transport protocol and port number explicitly given), following the procedures in [14], the UE performs an A query. If 
the recommended format is not followed, the UE might need to perform N APTR or/and SRV queries. 

Example of the recommended format for the SIP URI configured in the UE pointing to the outbound proxy: 

sip:outbound'proxy . my-operator.com : 5060;transport=^dp;comp=*sigcomp 

8.3.2 HTTP URL resolution 

The UE resolves a HTTP URL according to (1 2] or to best current practice. 

NOTE: The Im r^uest is sent to a pioxy identified by a configured address in case a WAP or HTTP proxy is 
used. In that case the proxy resolves the HTTP URL according to [12] or to best current practice. 

8.4 Early Session dialog establishment 

The early session provides the instant personal communication for end-user. The early session enables the UE to 
communicate the IP addresses and ports, which are used for sending the RTP/RTCP packets. 

The early session is used for service negotiation purposes between the end user and hisAier home PoC application 
server. 
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The early session is established for service negotiation purposes right after the initial regisu^tion, or the UE may i 
the early session for instant personal communication at any later time point (e.g. when the end-user activates the ii 
personal communication from the UE). 



8.5 



Instant Personal Talk 



In an Instant Personal Talk, user A establishes an PoC session with user B (via the PoC Server). Connection setup may 
be done either with early session procedure and SfP REFER or with SIP INVITE. 

In early session case the User A and User B establish early sessions after registration towards their PoC servers and 
during the connection establishment phase the session is established with using SIP REFER. If user A s terminal 
supports early session and auto answer is defined for user B Figure 2 's signalling sequence is applied NOTIFY 
message is sent to user A after the first talk buist. 



User A 



Button down 



Ready 



(1) REFER 



. Floor granted _ 
(3) 202 Accepted 



PoC Server 



UserB 



Floor taken 



Figure 2: Early session and auto answer procedure 



User A sends a SIP INVITE to the PoC Server including user B»s address in a body whose type is 
appIicatioii/vnd.siemensericssonmotorola.PoC. When the PoC Server receives this RsTVlTE, it performs an authorization 
decision based on the Do-not-Disturb setting in the GMLS. If the invitation is authorized, the PoC Server inspects the 
app!ication/vnd,siemensericssonmotoroIa.PoC body to discover user B's address and, depending on the network 
configuration, it initiates early media procedures (optional) or late media procedures. 

]l^tJ^^ ^^^^"^ configured to use the optional early media procedures^ it will, as shown in Figure 3. answer the 
INVITE with a -202 (Accepted) response. This response, together with the "floor grant" message from the talker 
arbitration process, mfom:is user A that user B has not been reached yet, but that the PoC Server is already prepared to 
receive media. The PoC Server will buffer all the media received from user A until it can be delivered to user B When 
user B IS finally contacted, the PoC Server informs user A about this using a NOTIFY request 



User A 

Button down 



Ready 



(1) INVITE 



(3) 202Aocepted 



— <4)ACK • 
Floor granted 

- (7) NOTIFY 
. (8) 200 OK 



PoC Server 



UserB 



(2) INVITE 



<S)200OK 
(6}ACK . 



Floor taken 
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Figure 3: Early media and auto answer procedure 

If tlie PoC Server is configured to use the late media procedures, it will, as shown in Figure 3 simply relay the responses 
received from user B to user A. 



User A 

Button down 



PoC Server 



User B 



Ready 



(1)INViTE 



<4) 180 Ringing 



(6) 200 OK 
. (7)ACK . 



Floor granted 



(2) INVITE - 

(3) 180 Ringing 

(5) 200 OK 



Floor taken 
— (8>ACK 



Figure 4: Late Media and Manual answer procedure 

Once the session has been established, either user A or user B can tenninate it at any time. In case of inactivity, the PoC 
Server can also terminate the session (no talk bursts within a configured time period). 



8.6 Ad-hoc Instant Group Talk 

In an Ad-hoc Instant Group Talk, user A establishes a PoC session with a set of users (via the PoC Server). 

For tiic early media procedures and the late media procedures are similar to those described in figures 3 and 4. The 
difference is that in an Ad-hoc Instant Group Talk, the application/vnd-poc.refer-to body of the initial INVITE from 
user A will contain more than one addres. Therefore, the PoC Server will send more than one INVITEs as a result. 
However, the fact that there are multiple INVTTEs triggered by user A's initial INVITE is hidden from user A. The PoC 
Server will send to user A a single NOTIFY in the eariy media case and a single 180 (Ringing) response m the manual 
answer case. When using the optional early media procedures for ad-hoc groups, the PoC server begins to play the 
media when the first invited party accepts. 

For the early session case procedures arc similar to those described in figure 3. The difference is tfiat in the REFER 
from user A will contain more than one address. PoC server will initiate several session setups towards B parties. The 
setup will be done with auto or manual answering mode depending on the Bs configuration. 

Note that, according to the description above, an instant personal talk (sub-clause 8.4) is only a special case of an Ad- 
hoc Instant Group Talk. Therefore, in all cases the user portion of the Request-URl of the initial INVITE will be set to 
the pre-configured ad-hoc string. The PoC Server will return in the Contact header of the final response for the INVFTE 
a unique identitier for the Instant Personal or Instant Group Talk. 

8.7 Instant Group Talk 

The signaling messages exchanged to establish an Instant Group Talk are the same as for an Ad-hoc Instant Group Talk. 
The only difference is that the Instant Group Talk has an already existing identifier while the identifier for the Ad-hoc 
Instant Group Talk was created at establishment time. Therefore, the Request-URI of the initial INVITE will be set to 
the identifier of the Instant Group Talk, as opposed to the Ad-hoc case where the "ad-hoc** convention for the user part 
is used. 



8.8 Chat Group Talk 

In a Chat Group Talk, a user joins an existing chat group. Existing, in this context, means that a unique identifier has 
been previously allocated for the chat group. Thus, both Chat Group Talks and Instant Group Talks have previously 
existing identifiers. The difference is that in an Instant Group Talk, when the first user joins the group, all the members 
of that Instant Group Talk are invited by the PoC Server. In a Chat Group Talk, when a user joins the group, no other 
user is implicitly invited. 
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8.9 Instant Personal Alert 

An Instant Personal Alert is a request from user A to user B for user B to establishes an Instant Personal Talk with user 
A. Instant Persona) Alerts are similar to a call back service in the world of traditional telephony. They are implemented 
using the SIP N4ESSAGE method. User A is informed of the delivery result of the instant personal alert. 
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ANNEX A (informative): Known 3GPP/OMA divergence 

PoC industry specification phase I is based on 3GPP and IETF standards where feasible. In order to overcome 
limitations of the existing technology, the PoC phase 1 specifications contain some deviations from the 3GPP standards. 
Careful evaluation of these deviations is required in subsequent releases of Push-to-talk specification. These 
divergences included in the industry specification do not imply requirements on the 3GPP/OMA standards but the 
OMA standards work should follow and be aligned with the 3GPP IMS specifications as much as possible. 

This annex captures the known divergences from the 3GPP specification. 

• IP version 

The PoC phase 1 specification supports IPv4 only 

• Authentication and intc gritv protection , . ^/-,od 
The PoC phase I specification supports HTTP digest in place of the IMS-AKA specified by 3GPP. 

mPoCph^c 1 specification docs not provide for the support of the IMS headers related to the policy control 
(Go intcr&ce). 

• CSCF discovery , . j l- • i j *u 
The PoC phase I specifications describe the parameters which are required to be configured - this includes the 
contact address of the SIP proxy which the terminal will communicate with. 

• Provisionin g; (}f private user TP . , ^ ^ j .t- • i j .u^ 
The PoC phase 1 specifications describes the parameters which are required to be configured - this includes the 
private user identifier. Jn 3GPP this is located on the ISIM or derived firom the USIM. 

TlwPoC^se I specifications describes floor control. Tliere is no suitable floor control standardized within 
the industry. 

• Group List Management ^ * 

The PoC phase I specifications describes a group list management protocol. The group list management work 

in 3GPP is still ongoing. 

• PoC header extension - i j u 
The PoC phase 1 specifications describes header extensions for identiftring that the signaling is related to the 

PoC service. 

• Initial-- Re- & De-reeistr ation procedures ^ . 

Hie PoC phase 1 specificaUons do not use all the 3GPP specified SIP header fields and parameters and 
additionally the PoC phase 1 specifications use PoC specific header fields and parameters. 

• Reject and Error Codes in Sessions 

The PoC phase 1 specifications have specific usage of reject and error codes. 

• Conferencing , _ , 
The overall POC functionality has similarities with currently ongoing 3GPP Rel6 conferencing work. Further 
alignments of these two activities are needed. 

• Group Identities 

The PoC phase 1 specification defines a mechanism for creating group identities. 3GPP has not yet completed 
the work on group management including handling of group identities and the Ut reference point. 

• Implicit subscription to refer state event 

The PoC phase I specifications establish with SIP INVITE method an implicit subscription which is not 
specified in 3GPP nor IETF. 
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